Today, the HyperText Transport Protocol (HTTP) constitutes the primary means for the delivery of content in the World Wide Web (WWW). HTTP is a text-based, stateless application layer protocol that defines a request/response-based message exchange mechanism between an HTTP client and an HTTP server. In the HTTP client-server model, an HTTP request is issued by an HTTP User Agent Client, while the HTTP response to the request comes from an HTTP User Agent Server.
Increasing demand for personalized WWW services has led to the development of HTTP stateful sessions comprising two or more (nominally independent) pairs of HTTP request and response messages. Currently, the dominant approaches to HTTP session administration are cookies, parameters in HTTP Universal Resource Locators (URLs) and so-called Fat URLs.
As regards cookies, the memorandum RFC2965 published by the Internet Engineering Task Force (IETF) and titled “HTTP State Management Mechanism” proposes several HTTP headers capable of conveying state information between the endpoints of an HTTP request-response message exchange. Cookies are defined as Attribute Value Pairs (AVP) of arbitrary names and values that may be accompanied by a range of predefined parameters as described in RFC2965. In a single HTTP request or response message, one or more cookies may be included as required.
An example of an HTTP request containing cookies is the following:                GET URI HTTP/1.1        Cookie: dialog-id=ali2alice1;method=bye        
This HTTP request contains two cookies that collectively identify the present state of a session. The first cookie defines attribute ‘dialog-id’ as ‘ali2alice1’, while the second cookie assigns to attribute ‘method’ the value ‘bye’.
Another possibility for keeping HTTP state information are HTTP parameters and query components. It is well known that URL schemes base their URL syntax on a nine-part general format (see RFC2396):
 <scheme>: // <user> : <password>@<host> : <port>/<path> ; <params> ? <query>#<frag>
Using this format, it is possible to convey session state information to remote network applications either as parameters or as query components. The following code listings illustrate two HTTP requests of an HTTP client to deliver session state information to an HTTP server.
Signaling session state information as URL parameters:                GET path;dialog-id=ali2alice1;method=bye HTTP/1.1 host: URI        
Signaling session state information as URL query components:                GET path?dialog-id=ali2alice1&method=bye HTTP/1.1 host: URI        
In both cases the HTTP server is informed that the current values for the attributes ‘dialog-id’ and ‘method’ are and ‘bye’, respectively.
Fat URLs are extended versions of URLs, suffixed with information used to identify the current state of an HTTP session. The following HTTP request illustrates how state information can be included in the path indication of an URL:                GET path/dialog-id=ali2alice1/method=bye HTTP/1.1 host: URI        
In the above example, the HTTP client issues a request to an HTTP server who is aware that the last two path segments correspond to session state information. In this particular case, the attribute ‘dialog-id’ is equivalent to ‘ali2alice1’ and the attribute ‘method’ is equivalent to ‘bye’.
While HTTP constitutes the primary means for content distribution in the WWW, the Session Initiation Protocol (SIP) is the primary signaling protocol on the control plane of the IMS (Internet Protocol Multimedia Subsystem) and other service provisioning networks. SIP is a text-based protocol used for authorizing user access as well as establishing, controlling and terminating media sessions between applications hosted by SIP enabled endpoints.
Similar to HTTP, SIP is based on the transmission of request and response messages. These messages are exchanged between User Agents installed on the communicating SIP endpoints. An SIP User Agent can either act as a User Agent Client (when sending a request message) or as a User Agent Server (when responding to the request message with a response message).
SIP defines that one or more media sessions between two SIP endpoints can only be established within the context of an SIP dialog. The dialog is a conceptual relation between the involved SIP endpoints that is maintained by the Transaction User Layer of the SIP Protocol Layers. In practice, a dialog is manifested as a collection of information that reflects the current state of the dialog for each endpoint. As understood herein, each SIP dialog comprises one or more SIP transactions, and each SIP transaction involves one or more messages (typically one request message and one or more response messages). In this sense, each SIP message can be regarded as part of an SIP transaction.
Each SIP dialog is identified by an identifier (the so-called dialog-ID) that is formed by a number of attributes negotiated between the SIP endpoints during initiation of a session and remaining valid for the lifetime of the dialog. Specifically, the dialog-ID of a dialog between a User Agent Client and a User Agent Server (the two endpoints of a SIP dialog) is defined as:
Dialog (-ID)=Call-ID, local tag (To-header tag of dialog response), remote tag (From-header tag of dialog request)
SIP and SIP's Universal Resource Identifiers (URIs) follow the guidelines set by RFC2396. The general form of a SIP URI as defined in RFC3261 has the following syntax:                sip:user:password@host:port;uri-parameters?headers        
The SIP URI structure allows for the inclusion of several parameters and headers within its generic form.
While HTTP is the standard protocol for the delivery of content in the WWW, there currently exists no documented or implemented solution that would allow HTTP enabled user equipment to initiate, conduct and terminate sessions with an SIP User Agent.